<html>
<head><meta charset="utf-8"><title>pre-pre-pre RFC: allowlist for unsafe and/or linking · general · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/index.html">general</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html">pre-pre-pre RFC: allowlist for unsafe and/or linking</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="230819662"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230819662" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230819662">(Mar 18 2021 at 06:40)</a>:</h4>
<p>This is an idea that would primarily be exposed to users as a <code>Cargo.toml</code> setting, but that would need support within <code>rustc</code> for it to work.</p>
<p><strong>Summary:</strong> In <code>Cargo.toml</code> you can set an "allow list" for <code>unsafe</code> and also for linking.</p>
<ul>
<li>If there <strong>is not</strong> an allow list set, it's the same as allowing everything everywhere. This is not only for backwards compatibility, but also for ease of getting a new project started. You don't want to have to type all sorts of things just to get started.</li>
<li>If there <strong>is</strong> an allow list set then only the allowed crates can use either <code>unsafe</code> and/or linking (depending on if you have either or both allow lists defined).</li>
<li>Each of these abilities is allowed independently on a per-crate basis.</li>
<li>If any crate in the build (including transitive dependencies) attempts to use an ability that isn't allowed, the build fails with an appropriate error message about who wanted to do what, where, etc.</li>
<li>The standard library crates are always allowed. If at some future time we have it so that you're able to specify what standard library crates you use from within your <code>Cargo.toml</code> we can revisit this detail.</li>
</ul>
<p>Now, in terms of raw versioning, this <em>does</em> make some semver approved updates into breaking changes. However, that's entirely the point. If I've examined crates FooA and FooB for what FFI code they're linking in, and then a patch release of FooC is unexpectedly doing some linking when it wasn't before, then I <em>sure do</em> want the build to halt with a message, and I can either check what FooC thinks it's doing now and add it to the allowlist or I can revert to an earlier version of the crate.</p>
<p><strong>Unresolved Issues:</strong> It's currently slightly unclear how <code>macro_rules!</code> should interact with the allowlist system. They kinda "inter-mix" together two crate spans when they expand. Which side of that cross-crate interaction do you put on the allowlist? My leaning is toward whichever crate uses the <code>unsafe</code> block to mask away the unsafe action, but I could see people wanting it to always be the macro use site, or maybe even some other system.</p>
<p>cc <span class="user-mention" data-user-id="239881">@Josh Triplett</span></p>



<a name="230861133"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230861133" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230861133">(Mar 18 2021 at 13:20)</a>:</h4>
<p>I'd love to have this option in some form or shape <span aria-label="heart eyes" class="emoji emoji-1f60d" role="img" title="heart eyes">:heart_eyes:</span> </p>
<p><strong>Regarding the macros</strong></p>
<p>If we forget the ability for macros to forge spans by using proc-macros (but I don't think that's an actual issue, since proc-macros may, with <code>build.rs</code> scripts, join the group of operations that "need to be trusted"), then the span of the <code>unsafe</code> used for a block or an impl (remember, <code>unsafe fn</code>s and <code>unsafe trait</code>s are harmless on their own) could indeed be used to see whom to blame.</p>
<p>Consider, for instance:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="cp">#[macro_export]</span><span class="w"></span>
<span class="fm">macro_rules!</span><span class="w"> </span><span class="n">NonZeroU8</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="p">(</span><span class="mi">0</span><span class="p">)</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="p">(</span><span class="cp">$crate</span>::<span class="n">core</span>::<span class="fm">compile_error!</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="s">"Invalid input!"</span><span class="w"> </span><span class="p">});</span><span class="w"></span>
<span class="w">    </span><span class="p">(</span><span class="mi">1</span><span class="p">)</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="p">(</span><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="cp">$crate</span>::<span class="n">core</span>::<span class="n">num</span>::<span class="n">NonZeroU8</span>::<span class="n">new_unchecked</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span><span class="w"> </span><span class="p">});</span><span class="w"></span>
<span class="w">    </span><span class="cm">/* similar for 2 to 255 */</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>Then this is the classic macro counterpart of <code>fn { unsafe { … } }</code> (that is, a caller writing non-<code>unsafe</code> code only cannot cause UB by calling this macro, see <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/278#issuecomment-791386088">my lengthy post at UCG</a>)  and indeed the crate defining the macro would need to be trusted for the crate to be usable or for its macro to be callable.</p>
<p>Now consider:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="sd">/// Transmutes `$expr` while remaining within the `$HKT` realm.</span>
<span class="sd">/// Useful to lengthen lifetimes:</span>
<span class="sd">/// ```rust</span>
<span class="sd">/// let local = 42;</span>
<span class="sd">/// let _: &amp;'static i32 = careful!( &amp;local =&gt; &amp;'_ i32 );</span>
<span class="sd">/// //                                         ^^</span>
<span class="sd">/// //                                         HKT</span>
<span class="sd">/// ```</span>
<span class="cp">#[macro_export]</span><span class="w"></span>
<span class="fm">macro_rules!</span><span class="w"> </span><span class="n">careful</span><span class="w"> </span><span class="p">{(</span><span class="w"> </span><span class="cp">$expr</span>:<span class="nc">expr</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="cp">$HKT</span>:<span class="nc">ty</span><span class="w"> </span><span class="p">)</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="p">(</span><span class="w"></span>
<span class="w"> </span><span class="c1">// trick to avoid having `$expr` be evaluated within the `unsafe` block</span>
<span class="w"> </span><span class="c1">// vvvvvvvvvvvvvvvvvv</span>
<span class="w">    </span><span class="k">match</span><span class="w"> </span><span class="cp">$expr</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">expr</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="cp">$crate</span>::<span class="n">core</span>::<span class="n">mem</span>::<span class="n">transmute</span>::<span class="o">&lt;</span><span class="cp">$HKT</span><span class="p">,</span><span class="w"> </span><span class="cp">$HKT</span><span class="o">&gt;</span><span class="p">(</span><span class="n">expr</span><span class="p">)</span><span class="w"> </span><span class="p">}}</span><span class="w"></span>
<span class="p">)}</span><span class="w"></span>
</code></pre></div>
<p>* Seen in <a href="https://docs.rs/miniserde">https://docs.rs/miniserde</a> internals (without the match trick, but not exported).</p>
<p>This one is actually an <code>unsafe fn</code>-like macro, which uses the word "careful" as an "unsafe" synonym. For an exported macro, I don't think that's enough, it should, at the very least contain <code>unsafe</code> in its name. Something like <code>unsafe_transmute_elided_lifetimes</code> or whatever (note that in the case of miniserde, since it is a private macro, then much like a technically unsound <code>fn  { unsafe { … }}</code> is not unsound if within a privacy boundary, this macro isn't either).</p>
<p>But, as I mentioned in that UCG issue, even just putting <code>unsafe</code> in the name isn't enough (at least if we take into account the proposal in this thread): the macro here can do two things:</p>
<ul>
<li>It can become an actual <code>unsafe macro</code> by not expanding to an <code>unsafe</code> block inside it, thus requiring that the caller provide it: <code>unsafe { transmute_lifetimes!( … ) }</code>. This solution is the best-looking one, but is not always possible for all macros (consider a macro that expands to an <code>unsafe impl</code>, in the type-definition realm: an <code>unsafe { … }</code> block in the expression/statement realm won't affect it):</li>
</ul>
<div class="codehilite" data-code-language="Diff"><pre><span></span><code>  #[macro_export]
  macro_rules! transmute_lifetimes {( $expr:expr =&gt; $HKT:ty ) =&gt; (
<span class="gd">-     match $expr { expr =&gt; unsafe { $crate::core::mem::transmute::&lt;$HKT, $HKT&gt;(expr) }}</span>
<span class="gi">+     $crate::core::mem::transmute::&lt;$HKT, $HKT&gt;($expr)</span>
  )}
</code></pre></div>
<ul>
<li>It can require the caller pass it / provide it an <code>unsafe</code> token that the macro will use to emit its <code>unsafe</code> stuff, something like <code>transmute_lifetimes!(unsafe: …)</code>:</li>
</ul>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="cp">#[macro_export]</span><span class="w"></span>
<span class="fm">macro_rules!</span><span class="w"> </span><span class="n">transmute_lifetimes</span><span class="w"> </span><span class="p">{(</span><span class="w"> </span><span class="cp">$unsafe</span>:<span class="nc">ident</span><span class="w"> </span>: <span class="cp">$expr</span>:<span class="nc">expr</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="cp">$HKT</span>:<span class="nc">ty</span><span class="w"> </span><span class="p">)</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="p">(</span><span class="w"></span>
<span class="w">    </span><span class="cm">/* some validation that `$unsafe` matches the `unsafe` token could be required,</span>
<span class="cm">     * or we could even add a new `:unsafe` capture kind */</span><span class="w"></span>
<span class="w">    </span><span class="k">match</span><span class="w"> </span><span class="cp">$expr</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">expr</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="cp">$unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="cp">$crate</span>::<span class="n">core</span>::<span class="n">mem</span>::<span class="n">transmute</span>::<span class="o">&lt;</span><span class="cp">$HKT</span><span class="p">,</span><span class="w"> </span><span class="cp">$HKT</span><span class="o">&gt;</span><span class="p">(</span><span class="n">expr</span><span class="p">)</span><span class="w"> </span><span class="p">}}</span><span class="w"></span>
<span class="p">)}</span><span class="w"></span>
</code></pre></div>
<p>As you can see with this last approach, <strong>the crate defining this macro wouldn't need to be trusted</strong>, since it does not perform any <code>unsafe</code> on its own / the trust is required for the caller that feeds it the <code>unsafe</code> capabilities, and so <strong>it's the caller who would need to be trusted</strong>.</p>



<a name="230862799"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230862799" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230862799">(Mar 18 2021 at 13:30)</a>:</h4>
<p><strong> Fine-grained capabilities <em>vs.</em> a trust "boolean" </strong></p>
<p>I think the proposal goes in the direction of a boolean "trust" mechanism, <em>vs.</em> more fine-grained capabilities which we may have seen suggested in the past (fs access, network access, unsafe, <em>etc.</em>). I think this is a more realistic approach: if a dependency is not to be trusted to do one operation correctly, it is weird to envision allowing it to do other stuff. The proposal thus mentions <code>unsafe</code> and/or linkeage, but I think this could and should cover other stuff: <code>build.rs</code> scripts, for instance, represent code that is <em>run</em> the moment one merely <em>checks</em> their code, which can happen very easily when IDEs are involved. In a similar fashion, proc-macros are as powerful a <code>build.rs</code> scripts, while also having the ability to emit <code>unsafe</code>-using code. So the line between each dangerous thing is blurry, and seems unwarranted.</p>
<p>That's why, if we put IO access aside (since that is something that can be better tackled with sandboxing, and something that would be too limiting to prevent crates to do), we can then consider the initial group of ops to be trusted to be: <code>unsafe</code> &amp; linkeage, <code>build.rs</code> scripts, and proc-macros (that last one could be loosened in the future when and if proc-macros happen to be run in a sandboxed environment (<em>e.g.</em>, wasm-interpreted).<br>
As I mentioned, including proc-macros to this list incidentally solves the issue of forging spans <em>w.r.t.</em> my post above about macros and <code>unsafe</code> responsibility.</p>



<a name="230867237"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230867237" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230867237">(Mar 18 2021 at 13:57)</a>:</h4>
<p><strong> A tool to fight supply-chain attacks? </strong></p>
<p>In the context of supply-chain attacks, besides using <code>cargo-audit</code> to mitigate the problem of malicious takeover of dependencies, or fully committing to a disciplined usage of <code>cargo-crev</code> (the ideal approach, but too costly in human effort to be systematically used), this proposal of using an allow list appears to be an interesting extra defensive tool. At the very least, an allow list can definitely protect against "clumsy code" (say, a beginner that writes <code>unsafe</code> code incorrectly), but I have to admit I am skeptical of the effectiveness of this approach against fully malicious code: <strong>while preventing sneaky additions of <code>build.rs</code> scripts or <code>proc-macro = true</code> crates can have a non-negligible impact against malicious dependencies</strong> (and in that regard I find the allow-list approach to be a desirable thing within the Rust ecosystem), one needs to be honest and admit that preventing <code>unsafe</code> code or linkeage won't do that much, since fs-interacting functions or even a fully-fledged <code>process::Command</code> invocation are non-<code>unsafe</code> operations.</p>
<ul>
<li>TL,DR: an allow list can definitely help fight compile-time malicious code execution, but it can't be useful against runtime malicious code execution (without being too oppressive).</li>
</ul>
<p>That being said, since sandboxing the execution of code (tests, examples, binaries) is quite useful to fight runtime malicious code execution, a combination of these two tools could be a quite simple way to <em>mitigate</em> malicious takeover of dependencies.</p>
<p><strong> Semver </strong></p>
<p>This leads to the fact that this allow-list does not play well with the conventional semver approach, but that makes sense: the very design of semver opens the doors to supply-chain attacks, and if an allow-list helps mitigate the latter, then it will necessarily hinder semver compatibility. So it's not a bad thing <em>per se</em>.</p>
<p>I think it is mainly a question of "education" / polishing the areas that "the semver contract" should cover: if we consider that performing any of the operations the allow-list tackles (either directly, or transitively) for a crate that used not to, should be considered a breaking change, then this allow list idea can actually play quite well with the semver design.</p>
<p>Another idea is that those that really care about this opt-in allow list could be opting into being more semver-fragile, so the responsibility of breakage would fall onto their shoulders rather than the ecosystem's. For instance, I consider that if a dev (let's call them D) decides to use an allow-list, then they ought to be tracking their <code>Cargo.lock</code> file too, so that if a dependency performs a minor semver bump that adds a new dependency not included in D's allow-list, then "that new dependency will simply not be sneakily added thanks to D's <code>Cargo.lock</code> file" (more precisely, such addition could only be accompanying a <code>Cargo.toml</code> change within D's repository (≠ sneaky, for instance, the CI run for that commit would detect the breakage, and allow D to fix the situation), never sneakily and abruptly causing "unrelated" CI breakage).</p>
<p><strong> <em>Quid</em> of transitivity of allow lists </strong></p>
<p>This leads to a final interrogation, which is where would the allow list be defined: I assume they would act like <code>[patch]</code> sections, living within a workspace and being applied to it, and being otherwise ignored by the dependents (or could a dependent directly trusting / allowing your crate lead to your allow-list being appended to theirs?)</p>



<a name="230867829"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230867829" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230867829">(Mar 18 2021 at 14:00)</a>:</h4>
<p>I wouldn't say that an unsafe impl is harmless on its own. Code that is sound in the presence of only correct impls of an unsafe trait can be unsound in the presence of incorrect impls. However, in this case the fault is with the impl.</p>



<a name="230868302"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230868302" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230868302">(Mar 18 2021 at 14:03)</a>:</h4>
<p>AFAIK, I did not say that <code>unsafe impl</code>s were harmless (if I have, that's a typo and I probably meant an <code>unsafe trait</code>)</p>



<a name="230868494"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230868494" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230868494">(Mar 18 2021 at 14:04)</a>:</h4>
<p>ah, so you did</p>



<a name="230868825"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230868825" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230868825">(Mar 18 2021 at 14:06)</a>:</h4>
<p>I do mention at some point that something like:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">impl</span><span class="w"> </span><span class="nb">Sync</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="err">…</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>doesn't work (yet), that is, that we don't have <code>unsafe</code> blocks at the item-level (if we had, these would be a more ergonomic solution for <code>unsafe macro</code>s than requiring they be given the <code>unsafe</code> token)</p>



<a name="230868828"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230868828" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230868828">(Mar 18 2021 at 14:06)</a>:</h4>
<p>Regarding malicious code: In the initial chat about this, Josh and I decided that we can't realistically prevent actually malicious attacks, so we opted to aim for this smaller goal of preventing the major "blunders" rather than "attacks", if that makes sense. Until we can sandbox build scripts and proc macros we're not aiming to claim secure compilation.</p>



<a name="230869133"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230869133" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230869133">(Mar 18 2021 at 14:08)</a>:</h4>
<p>Yep, that's what I meant with "clumsy" code. I still wanted to think a bit out lout about the supply chain "menace": using different approaches to tackle compile-time and runtime seems meaningful to me</p>



<a name="230873100"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230873100" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230873100">(Mar 18 2021 at 14:32)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking/near/230868828">said</a>:</p>
<blockquote>
<p>Regarding malicious code: In the initial chat about this, Josh and I decided that we can't realistically prevent actually malicious attacks, so we opted to aim for this smaller goal of preventing the major "blunders" rather than "attacks", if that makes sense. Until we can sandbox build scripts and proc macros we're not aiming to claim secure compilation.</p>
</blockquote>
<p>there's too many joshes <span aria-label="laughing" class="emoji emoji-1f606" role="img" title="laughing">:laughing:</span> I assume you mean <span class="user-mention silent" data-user-id="239881">Josh Triplett</span></p>



<a name="230879878"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230879878" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230879878">(Mar 18 2021 at 15:10)</a>:</h4>
<div class="codehilite" data-code-language="Text only"><pre><span></span><code>error[E0034]: multiple applicable items in scope
 --&gt; src/lib.rs:9:35
  |
9 | const _WHO: () = SetOfZulipUsers::Josh;
  |                                   ^^^^ multiple `Josh` found
  |
note: candidate #1 is defined in an impl of the trait `Triplett` for the type `SetOfZulipUsers`
 --&gt; src/lib.rs:1:18
  |
1 | trait Triplett { const Josh: () = (); }
  |                  ^^^^^^^^^^^^^^^^^^^^
note: candidate #2 is defined in an impl of the trait `OtherPeople` for the type `SetOfZulipUsers`
 --&gt; src/lib.rs:2:21
  |
2 | trait OtherAwesomePeople { const Josh: () = (); }
  |                            ^^^^^^^^^^^^^^^^^^^^
help: disambiguate the associated constant for candidate #1
  |
9 | const _WHO: () = Triplett::Josh;
  |                  ^^^^^^^^^^^^^^
</code></pre></div>



<a name="230880761"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230880761" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230880761">(Mar 18 2021 at 15:14)</a>:</h4>
<p>I'm shocked - shocked! - to find that I only rate "OtherPeople" <span aria-label="cry" class="emoji emoji-1f622" role="img" title="cry">:cry:</span></p>



<a name="230881614"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230881614" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230881614">(Mar 18 2021 at 15:19)</a>:</h4>
<p><code>git commit --fixup -m 'Fixed missing `Awesome` qualifier on `OtherPeople`'</code></p>



<a name="230979433"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/pre-pre-pre%20RFC%3A%20allowlist%20for%20unsafe%20and/or%20linking/near/230979433" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> isHavvy <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/pre-pre-pre.20RFC.3A.20allowlist.20for.20unsafe.20and.2For.20linking.html#230979433">(Mar 19 2021 at 05:45)</a>:</h4>
<p>Can this be implemented outside of cargo using some new tool e.g. <code>cargo allow_unsafe_check</code>? If the experimentation can be done without an RFC, perhaps it should be?</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>